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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration 
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by 
functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service (QoS). The CM actions are 
initiated either as single actions on single NEs of the 3G network, or as part of a complex procedure involving actions 
on many resources/objects in one or several NEs. 

Background 

Traditionally, multiple name conventions have been used by different vendors' NEs, or even within the same vendor, to 
name network resources. The following problems have thus arisen: 

• Different classes of NE have used different name conventions. Network Management applications, when 
interfacing with these NEs, have been required to understand multiple name conventions to manage the NEs. 



• 



• 



Network management applications (e.g. Fault Management application), when interfacing with other 
applications (e.g. Configuration Management application, trouble ticket system) have been required to 
understand multiple name conventions. 

When a customer purchased multiple classes of NEs from the same or different vendors, the customer was 
confronted with multiple name conventions. 

Without a name convention, it is difficult to integrate IRP conformant vendors' resource name space (see 
subclause 3.1.5 for definition of name space) into the customer's Enterprise name space. 
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Benefits 

The benefits of using the subject name convention to name 3G network resources for network management purposes are 
as follows: 



• 



• 



A resource name is guaranteed to be unambiguous in that it refers to, at most, one network resource. 
Unambiguous naming of managed network resources is necessary for interoperability among managing 
applications and systems. 

The resource name syntax is specified such that management applications can be designed with assurance that its 
name-parsing algorithm needs not be modified in the future. We can derive this benefit only if the subject name 
convention is widely accepted. 

The root and upper portions of the name hierarchy are based on name infrastructure of Domain Name System (DNS) 
(see IETF RFC 2247 [5]). The subject name convention can naturally fit in DNS and can integrate well with other 
hierarchical naming systems, such as ITU-T Recommendation X.500 [2]. 
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1 Scope 

A more detailed background and introduction of the IRP concept is given in 3GPP TS 32.150 [16]. 

To perform network management tasks, co-operating applications require identical interpretation of names assigned to 
network resources under management. Such names are required to be unambiguous as well. The present document 
recommends one name convention for network resources under management in the IRP context. 

To facilitate integration of network management information obtained via multiple IRPs based on different 

IRP Solution Set technologies, identical network resource name semantics shall be conveyed in all IRPs. The present 

document specifies one such name convention. 

The present document also specifies an lOC/MOC name recommendation (see annex E) in order to avoid potential 
problems with valid characters in some programming languages. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] Void. 

[2] ITU-T Recommendation X.500 (1993): "Information technology - Open Systems Interconnection - 

The Directory: Overview of concepts, models and services". 

[3] T. Howes, ISBN 1-57870-070-1: "Understanding and Deploying LDAP Directory Services". 

[4] IETF RFC 1737 (1994): "Functional Requirements for Uniform Resource Names". 

[5] IETF RFC 2247 (1998): "Using Domains in LDAP/X.500 Distinguished Names". 

[6] IETF RFC 1035 (1987): "Domain names - implementation and specification". 

[7] IETF RFC 2253 (1997): "Lightweight Directory Access Protocol (v3): UTF-8 String 

Representation of Distinguished Names". 

[8] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 

Integration Reference Point (IRP): Information Service (IS)". 

[9] 3GPP TS 32.622: " Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[10] Void. 

[II] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 
[12] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[13] ISO/IEC 14977: "Information technology - Syntactic metalanguage - Extended BNF". 

[14] ISO/IEC 646: "Information technology - ISO 7-bit coded character set for information 

interchange". 
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[15] ISO/IEC 10646: "Information technology - Universal multiple-octet Coded Character Set (DCS)". 

[16] 3GPP TS 32.150: "Integration Reference Point (IRP) Concept and definitions". 

[17] 3GPP2 S.S0028-E 'OAM&P for cdma2000 (Overview, 3GPP R7 Delta Specification, 3GPP2 

Network Resource Model IRP)' 

[ 1 8] MEF Technical Specification MEF 7.1, Phase 2 EMS-NMS Information Model, October 2009 

[19] ATM Forum, Technical Committee, Network Management, M4 Network View CMIP MIB 

Specification 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [11] , 

3GPP TS 32.102 [12] and 3GPP TS 32.150 [16] apply. This subclause defines terms essential for understanding of 

name convention in the IRP context. 

3.1.1 Void 

3.1.2 Void 

3.1 .3 Managed Object and Networl< Resource 

In the context of the present document, a Managed Object (MO) is a software object that encapsulates the manageable 
characteristics and behaviour of a particular network resource. Examples of network resource are switch, scanner for 
monitoring performance data, cell, site, transmission links, satellite, operator profile, etc. In the present document, MO 
sometimes is referred to as MO instance. 

3.1.4 Name 

In the context of the present document, a name is restricted to the identification of a MO, that is, a software object 
representing a real network resource. 



3.1.5 Namespace 



A name space is a collection of names. This name convention uses a hierarchical containment structure, including its 
simplest form - the one-level, flat name space. This name convention does not support an arbitrarily connected name 
space, or graph structure, in which a named object can be both child and parent of another named object. 
Figure 1 shows some examples of supported and unsupported name spaces (this figure is from T. Howes, 
ISBN 1-57870-070-1 [3] and it provides useful information on name space design). 
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Supported 





Unsupported 
Figure 1 : Examples of supported and unsupported name spaces 



3.1 .6 Global Root and Local Root 

Names in name space are organised in hierarchy. An MO instance that contains another one is referred to as the superior 
(parent), whereas the contained MO instance is referred to as the subordinate (child). 

In modern network management, it is expected that the Enterprise name space be partitioned for implementations in 
multiple managed system (see annex C for reasons of name space partitioning). The parent of all MO instances in a 
single managed system is called the Local Root. The ultimate parent of all MO instances of all managed systems is 
called the Global Root. 

3.1 .7 Distinguished Name and Relative Distinguished Name 

A Distinguished Name (DN) is used to uniquely identify a MO within a name space. A DN is built from a series of 
"name components", referred to as Relative Distinguished Names (RDNs). ITU-T Recommendation X.500 [2] defines 
the concepts of DN and RDN in detail, using ASN.l, in the following way: 

DistinguishedName ::= RDNSequence 

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 

RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue 
AttributeTypeAndValue ::= SEQUENCE {type AttributeType, value AttributeValue} 

The present document references this ASN.l structure but it only uses single-valued (not multi-valued) RDN. 

From a DN of a MO, one can derive the DN of its containing MO, if any. This containment relation is the only relation 
carried by the DN. No other relation can be carried or implied by the DN. 

See annex B for a rule for MO designers to avoid ambiguity concerning the AttributeType of a DN string. 

See annex C for discussion of DN prefix. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ASN.l 

BER 

CM 

DC 

DN 

DNS 

EBNF 

FM 

IETF 

IOC 

IRP 



Abstract Syntax Notation One 
Basic Encoding Rules 
Configuration Management 
Domain Component 
Distinguished Name 
Domain Name Service 
Extended Backus -Naur Form 
Fault Management 
Internet Engineering Task Force 
Information Object Class 
Integration Reference Point 
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IS 

LDN 

MO 

MOC 

MOI 

NE 

NR 

NRM 

PM 

QoS 

RDN 

SS 

TMN 



Information Service 

Local Distinguished Name 

Managed Object 

Managed Object Class 

Managed Object Instance 

Network Element 

Network Resource 

Network Resource Model 

Performance Management 

Quality of Service 

Relative Distinguished Name 

Solution Set 

Telecommunications Management Network 



System overview 



4.1 System context 

Situations under which MO (representing network resource) names are used are as follows: 

a) MO names cross various Integration Reference Points (IRPs). 

EXAMPLE 1 : In the context of Alarm IRP 3GPP TS 32. 1 1 1 -2 [8] , IRP Agent notifies IRPManager of the alarm 
condition of a network resource. The DN of the MO, representing alarmed network resource, 
encoded as specified in the present document, is carried in the Managed Obj ect Instance 
parameter of the notification. 

EXAMPLE 2: In the context of Generic Network Resources IRP: NRM, 3GPP TS 32.622 [9], IRP Agent notifies 
IRPManager of the creation of new object. The DN of the newly created object, encoded as 
specified in the present document, is carried in the notification. 

EXAMPLE 3: In the context of Generic Network Resources IRP: NRM, 3GPP TS 32.622 [9], IRPManager 

requests IRP Agent to search for a particular object by specifying the start point of the search. The 
DN of the base object, upon which the search begins downward hierarchically, is carried in the 
request. 

b) Co-operating management applications need to exchange information that includes MO (representing network 
resource) names. 

EXAMPLE 4: A Fault Management (FM) application may request a trouble ticket system to open a new trouble 
ticket reporting the alarmed condition of a network resource by specifying, among other things, the 
MO name representing the alarmed network resource. The DN of the MO, encoded as specified in 
the present document, is included in the request. 

EXAMPLE 5: A Performance Management (PM) system that produces reports on performance of network 

resources. The DNs of the MOs, representing the reported network resources, encoded as specified 
in the present document, are printed on the report. 



5 Name Convention for IVIanaged Objects 

Network resources shall be named using the naming conventions in ITU-T Recommendation X.500 [2] with one 
restriction listed below. Central to the X.500 naming convention is the concept of the Distinguished Name (DN) (see 
subclause 3.1.7). 

The restriction is that this IRP name convention does not support multi-value RDN. Only single-value RDN is 
supported. 
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6 Representations of Distinguished Name (DN) 

A DN can be encoded and represented in many ways. The present document specifies one representation. Future work 
on IRP specifications may require the definition(s) of other representation(s).. 

The DN is encoded using the string representation. 

The DN string representation encoding scheme: 

shall be used for DNs exchanged through all IRP SS technologies, 

is in itself IRP SS technology neutral, and 

is subject to IRP SS technology specific handling, such as escaping, if required by such a technology. 
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String Representation of DN 



7.A Overview 

This clause specifies the string representation of DN. This work is based on IETF RFC 2253 [7]. A DN string 
representation, using the string-encoding scheme specified in the present document, is also a valid DN string according 
to IETF RFC 2253 [7]. 

The string-encoding scheme specified in the present document imposes further restrictions as compared to IETF 
RFC 2253 [7]. The most important restrictions are: 

Multi-valued RDN is not supported in the subject name convention. 

The asterisk character (see clause 7.2 bullet 3) is used to denote wildcard. The asterisk character shall not be 
used in DN . 

7.B Allowed character sets 

Subject to further restrictions described in the present document, the allowed characters for the string representation of 
DN are: 

Characters of ISO/IEC 646 [14] International Reference Version (IRV) coded character set, and 

Characters of standard coded character sets supporting and extending ISO/IEC 646 [14] IRV coded character set, 
i.e. ISO/IEC 10646 [15] coded character set. 

NOTE 1: ISO/IEC 646 [14] IRV coded character set is the international equivalent to the ANSI X3.4 ASCII coded 
character set. 

NOTE 2: The character set of ISO/IEC 646 [14] IRV corresponds to the subset of characters that range from 
Uh-0000 to UH-007F in the character set of ISO/IEC 10646 [15]. 

NOTE 3: The ISO/IEC 646 [14] IRV characters specifically referenced in this specification are further identified 
using ISO/IEC 10646 [15] character short identifier notation form "Uh-XXXX". 

7.1 Converting DN from ASN.1 to String 

Subclause 7.1.1 defines the algorithm to convert an ASN.l structured representation to one-string DN representation. 
Subclause 7.1.2 defines the algorithm to convert an ASN.l structured representation to multi-string DN representation. 

CORBA SS uses one-string DN representation. XML SS uses both one-string and multi-string DN representations. 

7.1.1 Rule for one-string DN 
7.1 .1 .1 Converting RDNSequence 

If the RDNSequence is an empty sequence, the result is the empty or zero length string. 

Otherwise, the output consists of the string encoding of each RDN in the RDNSequence (according to subclause 
7.1.1.2), starting with the first element of the sequence and moving forward toward the last element. 

The encoding of adjacent RDNs are separated by a comma character (' , ', UH-002C), to be consistent with IETF 
RFC 2253 [7]. 

White spaces adjacent to the comma character shall be ignored. 
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7.1.1.2 Converting RelativeDistinguishedName 

When converting from an RDN to a string, the output consists of the string encoding of the singleton 
AttributeTypeAndValue (according to subclause 7.1, i.e. 'Multi-valued RDN is not supported in the subject name 
convention.' ). 

Although ITU-T Recommendation X.500 DN supports multi-valued RDN, this specification supports single-valued 
RDN only. 

7.1.1.3 Converting AttributeTypeAndValue 

The AttributeTypeAndValue is encoded as the string representation of the AttributeType, followed by an 
equals sign character ('=', UH-003D), followed by the string representation of the AttributeValue. 

Although ITU-T Recommendation X.500 ASN.l AttributeValue and AttributeType support wide range of 
character representation, this specification supports a restrictive set of characters according to subclause 7.2. 

String representation of AttributeValue allows character escape mechanism such as the use of a reverse solidus 
character ('\', Uh-OOSC) followed by two hexadecimal digits to replace a character in a string. String representation of 
AttributeType does not allow character escape mechanism. 

EXAMPLE: "CN=Bef ore\ODAf ter , 0=Test , C=GB". In this example, the reverse solidus character and 

the two hexadecimal digits form a single byte in the code of the escaped character. The reverse 
solidus character followed by "OD" indicates a carriage return character. See annex B for a rule for 
MO designers to avoid ambiguity concerning the AttributeType of a DN string. 

7.1 .2 Rule for multi-string DN 

7.1 .2.1 Converting RDNSequence 

If the RDNSequence is an empty sequence, there is no equivalent multi-string DN output, i.e. there is no multi-string 
DN representation for empty RDNSequence sequence. 

Otherwise, the output consists of the string encoding of all RDNs in the RDNSequence (according to subclause 
7.1.2.2). 

One RDN encoding is within an NRM class associated XML element. A multiple RDNSequence would be converted 
into multiple RDN encodings, using multiple NRM class associated XML elements. They are arranged in a hierarchy in 
the XML document. The outer NRM class associated XML element represents the first RDN in the RDNSequence . 

7.1.2.2 Converting RelativeDistinguishedName 

When converting from an RDN to a string, the output consists of the encoding of the singleton 

AttributeTypeAndValue (according to subclause 7.1, i.e. 'Multi-valued RDN is not supported in the subject name 
convention.'). 

Although ITU-T Recommendation X.500 DN supports multi-valued RDN, this specification supports single-valued 
RDN only. 

7.1 .2.3 Converting AttributeTypeAndValue 

Within an NRM class XML element, there is an element such as <element name= "ManagedElement " > and 
there is another element <attribute name="id" type="string" use="required"/> which is 
inherited by using <extension base="xn:NrmClass" >. 

The AttributeType and AttributeValue are mapped to the former and latter XML elements. The 
AttributeType carries the IOC name while the AttributeValue carries the value of the IOC naming-attribute. 
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Although ITU-T Recommendation X.500 ASN.l AttributeValue and AttributeType support wide range of 
character representation, this specification supports a restrictive set of characters according to subclause 7.2. 

String representation of AttributeValue allows character escape mechanism (see 7.1.1.3). 



7.2 Character syntax 



This subclause specifies the character syntax for AttributeType and AttributeValue (The ISO/IEC 646 [14] 
IRV characters specifically referenced in this specification are further identified using ISO/IEC 10646 [15] character 
short identifier notation form "U+XXXX"', from note 3 subclause 7.B.). 

They are: 

1 . Any character except: 

comma character (' , ', U+002C), 
equals sign character ('=', U+003D), 
carriage return character (U+OOOD), 

- Une feed character (U+OOOA), 

- plus sign character ('+', U+002B), 
less-than sign character ('<', U+003C), 
greater-than sign character ('>', U+003E), 
number sign character ('#', U+0023), 

- semicolon character (' ; ', U+003B), 
reverse solidus character ('\', U+005C), 
quotation mark character (' " ', U+0022). 

2. The full stop character (' . ', U+002E). This character may be used in the AttributeValue whose 
AttributeType is "DC". An example is "DC=mark:eting . CompanyXYZ . com". This full stop character 
shall not be used in AttributeType. 

3. The asterisk character ('*', U+002A) is reserved to denote wildcard. Wildcard can be used as input to search or 
filter capabilities based on DN. For example, a client is not sure of the exact spelling of the AttributeValue 
(see clause 7.3), the client can use wildcard to represent one or more characters which are legal in that field. The 
asterisk character shall not be used in DN. 

7.3 EBNF of DN String Representation 

The formal definitions provided within this subclause consolidate several rules and concepts (null distinguished name, 
DN prefix, local DN, domain component type, class names starting with upper case characters, attribute names starting 
with lower case characters, classes with or without an "Id" naming attribute, attribute type and attribute value allowed 
characters, wildcard character). 

The following is the EBNF for DN in string representation (Extended Backus-Naur Form; see ISO/IEC 14977 [13] for 
more information): 

DistinguishedName = NullDN {* Distinguished Names shall not exceed *) 

I RegularDN ; {* 400 octets as specified in section 7.4 *) 

NullDN = ; {* empty string; null DN is specified in subclause 7.1.1 *) 

RegularDN = DNPref ixPlusRDNSeparator {* DN prefix and local DN *) 

, LocalDN ; {* are defined in annex C *) 
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DNPref ixPlusRDNSeparator 

NullDNPrefix 

NullRDNSeparator 

DNPref ixWithDomainComponent 

DNPref ixWithoutDomainComponent 

LocalDN 

RDNSeparator 

RDNSeparatorWhiteSpace 

DomainComponentRDN 

RegularRDN 

LocalRDN 

DCAttributeTypeAndValue 

RegularAttributeTypeAndValue 

LocalDNAttributeTypeAndValue 

AttributeTypeAndValueSeparator 

DCAttributeType 

DCAttributeValue 

DCLabelSeparator 
DCLabel 



{ NullDNPrefix , NullRDNSeparator ) 
I { DNPref ixWithDomainComponent , RDNSeparator ) 
I { DNPref ixWithoutDomainComponent , RDNSeparator ) 

; {* empty string *) 

; {* empty string *) 

DomainComponentRDN 
, { RDNSeparator , DomainComponentRDN } 
, { RDNSeparator , RegularRDN } ; 

RegularRDN 
, { RDNSeparator , RegularRDN } ; 

LocalRDN 
, { RDNSeparator , LocalRDN } ; 



{* use of optional white space *) 
{* is recommended to be avoided *) 



[ RDNSeparatorWhiteSpace ] 
, CommaChar 
, [ RDNSeparatorWhiteSpace ] ; 

[ CarriageReturnChar ] 
, { SpaceChar } ; 

DCAttributeTypeAndValue ; 

RegularAttributeTypeAndValue ; 

LocalDNAttributeTypeAndValue ; 

DCAttributeType 
, AttributeTypeAndValueSeparator 
, DCAttributeValue ; 

RegularAttributeType 
, AttributeTypeAndValueSeparator 
, RegularAttributeValue ; 

LocalDNAttributeType 
, AttributeTypeAndValueSeparator 
, RegularAttributeValue ; 

EqualsSignChar ; 

"DC" ; {* ISO/IEC 646 IRV U+0044/0043 Latin capital letters D&C *) 



DCLabel 
, { DCLabelSeparator , DCLabel 



{* this is specified *) 
{* in IETF RFC 1035 *) 



FullStopChar 



{* this is specified in IETF RFC 1035 *) 



LetterChar 

[ { LetterDigitHyphenMinusChar } 
, LetterDigitChar ] 



{* this is specified *) 
{* in IETF RFC 1035 *) 



RegularAttributeType 

LocalDNAttributeType 

NameOfClassWithldAttribute 
NamesOfClassAndNamingAt tribute 



LetterChar 

{ LetterDigitHyphenMinusChar 



{* this is specified *) 
{* in IETF RFC 2253 *) 



NameOfClassWithldAttribute {* definition selected shall *) 

I NamesOf ClassAndNamingAttribute ; {* be in accordance with the *) 

{* rules defined in annex B *) 
ClassName ; {* see rules defined in annex B *) 



ClassName 
, ClassNamingAttributeSeparator 
, NamingAttributeName ; 



{* see rules defined in annex B *) 



ClassNamingAttributeSeparator 
ClassName 

NamingAttributeName 



FullStopChar 



{* see rules defined in annex B *) 



CapitalLetterChar 

{ LocalDNAttributeTypeChar 



SmallLetterChar 

{ LocalDNAttributeTypeChar 



{* see recommendation on *) 
{* characters for class names *) 
{* in annex E 
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RegularAttributeValue 



{ AttributeValueChar - SpaceChar ) 
[ { AttributeValueChar } 

, { AttributeValueChar - SpaceChar ) 



{* this is *) 
{* specified in *) 
{* IETF RFC 2253 *) 



LocalDNAttributeTypeChar 
AttributeValueChar 
DNChar 
DNCharUnrestricted 

EscapedCharSequence 

ReservedChar 

Rfc22 5 3ReservedChar 

LetterChar 

LetterDigitChar 

LetterDigitHyphenMinusChar 

HexadecimalDigitChar 

LineFeedChar 

CarriageReturnChar 

SpaceChar 

QuotationMarkChar 

Numbers ignChar 

AsteriskChar 

PlusSignChar 

CommaChar 

HyphenMinusChar 

FullStopChar 

DigitChar 

SemiColonChar 
LessThanSignChar 
Equal sSignChar 
Great erThanSignChar 
CapitalLetterAtoFChar 

CapitalLetterChar 

ReverseSolidusChar 
SmallLetterAtoFChar 



DNChar - FullStopChar ; 

DNChar | EscapedCharSequence ; 

DNCharUnrestricted - ReservedChar ; 

? Character of ISO/IEC 646 IRV ? 
I ? Character of standard coded character set 
supporting and extending ISO/IEC 646 IRV ? 



ReverseSolidusChar 

2 * HexadecimalDigitChar 



{* this is specified *) 
{* in subclause 7.1.3 *) 



Rf c2253ReservedChar | CarriageReturnChar | LineFeedChar 
I AsteriskChar ; 

CommaChar | EqualsSignChar | PlusSignChar | LessThanSignChar 
I GreaterThanSignChar | Numbers ignChar | SemiColonChar 
I ReverseSolidusChar | QuotationMarkChar ; 

CapitalLetterChar | SmallLetterChar ; 

LetterChar | DigitChar ; 

: LetterDigitChar | HyphenMinusChar ; 

DigitChar | CapitalLetterAtoFChar | SmallLetterAtoFChar ; 

? ISO/IEC 646 IRV U+OOOA character line feed ? ; 

? ISO/IEC 646 IRV U+OOOD character carriage return ? ; 
' ; {* ISO/IEC 646 IRV U+0020 character space *) 
"' ; {* ISO/IEC 646 IRV U+0022 character quotation mark *) 
#' ; {* ISO/IEC 646 IRV U+0023 character number sign *) 
* ' ; {* ISO/IEC 646 IRV U+002A character asterisk *) 
+' ; {* ISO/IEC 646 IRV U+002B character plus sign *) 
, ' ; {* ISO/IEC 646 IRV U+002C character comma *) 
' - ' ; {* ISO/IEC 646 IRV U+002D character hyphen-minus *) 
. ' ; {* ISO/IEC 646 IRV U+002E character full stop *) 



'0' I '1' I '2' I '3' I '4' 
' 5 



{* ISO/IEC 646 IRV U+0030-0039 *) 
{* digits to 9 *) 



I '6' I '1' I '8' I '9 
{* ISO/IEC 646 IRV U+003B character semicolon *) 
{* ISO/IEC 646 IRV U+003C character less-than sign *) 
{* ISO/IEC 646 IRV U+003D character equals sign *) 
{* ISO/IEC 646 IRV U+003E character greater-than sign *) 



'A' I 'B' I 'C {* ISO/IEC 646 IRV U+0041-0046 *) 
'D' I 'E' I 'F' ; {* Latin capital letters A to F *) 

CapitalLetterAtoFChar | 'G' | 'H' {* ISO/IEC 646 IRV *) 

'I' I 'J' I 'K' I 'L' I 'M' I 'N' {* U+0041-005A *) 

'0' I 'P' I 'Q' I 'R' I 'S' I 'T' {* Latin capital *) 

'U' I 'V I 'W I 'X' I 'Y' I 'Z' ; {* letters A to Z *) 

{* ISO/IEC 646 IRV U+005C character reverse solidus *) 



\' 



'a' I 'b' I 'C 
'd' I 'e' I 'f 



{* ISO/IEC 646 IRV U+0061-0066 *) 
{* Latin small letters a to f *) 
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SmallLetterChar = SmallLetterAtoFChar | 'g' | 'h' {* ISO/IEC 646 IRV *) 

I 'i' I 'j' I 'k' I '1' I 'm' I 'n' {* U+0061-007A *) 

I 'o' I 'p' I 'q' I 'r' I 's' I 't' {* Latin small *) 

I 'u' I 'V I 'w' I 'X' I 'y' I 'z' ; {* letters a to z *) 



7.4 Maximum size of DN string 



The maximum length of a DN string, including RDN separators and including white spaces, shall not exceed 400 bytes 
(8-bit). 
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8 



Examples of DN in string representation 



This subclause gives a few examples of DN written in the string representation specified in the present document. 

EXAMPLE 1: "DC=com, DC=CompanyXYZ,DC=marketing, IRPAgent=ATMPVCBilling, 

Log=19990101131000 , AccountingRecord=100098". In this example, the name space 
aligns with DNS. The AttributeType of the top three RDN are "DC". Concatenation of the 
corresponding AttributeValues produces the DNS registered name, 

i.e. "marketing . CompanyXYZ . com". The top RDN is the Global Root because DNS defines 
"DC=com" as the root of its name space. That top RDN is the Local Root as well. 

EXAMPLE 2: "DC=marketing . CompanyXYZ . com, IRPAgent=ATMPVCBilling, 

Log=19990101131000 , AccountingRecord=100098". In this example, the name space 
aligns with DNS as well. Instead of using three RDNs to represent the DNS registered name, this 
example chooses to use one RDN. The top RDN is the Global Root (and Local Root as well). 

EXAMPLES: "SubNetwork=ABCNetwork, SubNetwork=TN2 ,MSCFunction=B5C010 0". In this 
example, the name space designer chooses not to name its objects under the DNS nor X.500 
scheme. The name space designer chooses to use "SubNetwork=ABCNetwork" as the Local 
Root of its name space (by looking at the DN string, it is not possible to say if the Local Root is 
the Global Root). DNs in this name space will start with that string as their Local Root. 

EXAMPLE 4: The following example illustrates the use of the comma character as separator for RDNs. It also 
illustrates the use of space and full stop characters as part of the legal character syntax for RDNs: 

"CN=John T. Mills, 0=Cyber System Consulting" 
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9 Usage Scenario 

9.1 DN prefix usage 

This subclause presents recommended steps designer uses to partition the Enterprise name space while building an 
Alarm IRP compliant NE (the Alarm IRP Agent). 

1. The NE designer specifies the NRM (e.g. 3GPP TS 32.622 [9]) for the NE. Suppose the NRM is a two level 
hierarchy with 3 classes like: 

Node 

I Port 

I CrossConnect 

2. The NE designer, based on the NRM and other design choices, decides that there are 7 instances within the NE 
that can report alarms, such as 

Port=l, Port=2, Port=3, Port=4, Port=5, CrossConnect=l, Node=l. 

3. The NE designer decides on the DN prefix (see annex C) and configures its system accordingly. Since NE 
designer will not know the customer's name space in advance, he would normally configure the DN prefix to 
reflect his test environment. The DN prefix can be configured to "Network;=test". The Global Root is 
"Network;=test". The Local Root is "Node=l". It should be noted that the NE should not hard code the DN 
prefix but should treat DN prefix as a system configuration parameter, settable. 

EXAMPLE 1 : At system start-up time. 

4. When constructing the alarm record (in coding phase), NE designer shall concatenate the name of the alarmed 
instance with the DN prefix to form the DN of his test environment. The resultant DN 

(e.g. "Network=test , Node=l , Port = 3") will be placed in the Managed Ob j ect Instance (MOI) 
field of the alarm record. 

5. The NE is sold to a customer. The customer administrator knows his Enterprise name space, the topology of his 
network and where the NE will be deployed. Based on the information, he configures the DN prefix of the NE. 

EXAMPLE 2: The customer administrator can configure it to: 

"DC=Tnark:eting . CompanyXYZ . com, Net=DS3BackBone , Station=TMR" 
The Global Root in this case is "DC=Tnark:eting . CompanyXYZ . com". 

6. At run time, whenever NE is reporting an alarm on Port = 3 via the IRP, the following string will be in the MOI 
field of the alarm record: 

"DC=mark:eting. CompanyXYZ . com, Net=DS3BackBone , Station=TMR, Node=l , Port=3" 
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Annex A (normative): 

Mapping of RDN AttributeType to Strings 

NOTE: This annex is normative for users of string representation. 

AttributeType of RDN is mapped into string for use in the DN string representation. This annex specifies the 
mapping. 

The AttributeType shall include all MO classes defined in the 3GPP Network Resource Model (NRM) IRP 
specifications such as the 3GPP TS 32.622 [9]. 

It can also include classes defined by other domain specific NRMs such as [17], [18] and [19]. Such inclusion is 
necessary where 3GPP -defined mobile access network is part of a Fixed Mobile Convergence network management 
environment. 

There is one AttributeType that is not defined in NRM of 3GPP TS 32.622 [9] or other domain specific NRMs as 
listed in the Introduction clause. This special AttributeType is used to denote the domain component of the DNS. 
The following partial DN string representations are examples to illustrate the valid use of "DC" strings for the three 
DNS domain components of "marketing . CompanyXYZ . com": 

"DC=com. CompanyXYZ .marketing, ..." 

- "DC=com,DC=CompanyXYZ,DC=marketing, ..." 

- "DC=com,DC=CompanyXYZ. marketing, ..." 

- "DC=com. CompanyXYZ, DC=marketing, ..." 

Table A.I : Example of RDN AttributeType Strings 



String 


AttributeType 


DC 


Domain component of DNS 


SubNetwork 


IVIO class name SubNetwork defined in NRM of 3GPP TS 32.622 [9]. 


etc. 


See note. 


NOTE: For each MO class name found in 3GPP set of specifications, its corresponding AttributeType String shall 
be identical to the class name with the leading character capitalised. 
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Annex B (normative): 

Rule for MO Designers regarding AttributeType 

interpretation 

NOTE: This annex is normative for users of one string representation. 

This annex discusses the two possible interpretations for the AttributeType of the DN string and estabHshes a rule 
for MO designers to avoid ambiguity concerning their usage. 

It also gives a rule for designing MO classes such that one DN string, regardless of the IRP SS technology used, will 
result in a unique reference to the corresponding network resource. 

First interpretation 

ITU-T Recommendation X.500 [2] uses the AttributeType (defined for use as the first component of the 
AttributeTypeAndValue of a RDN, see subclause 3.1.6) to identify one attribute of the subject MO for naming 
purpose. This AttributeType is called the naming attribute to distinguish itself from other attributes that may be 
present in the MO. 

Suppose the following is the MO class definition in pseudo notation and this MO class is inherited from root. 

Class Bsc { 
Attribute id; 
Attribute . . } 

Suppose further that the naming attribute is id. 

If this (first) interpretation is used for constructing the DN string, then the DN will be "... , id=123". MO class name 
cannot be derived from the DN string. The value of the AttributeValue contains the value of the naming attribute. 

Second interpretation 

Generally, this interpretation shall be preferred to the first interpretation. 

The AttributeType (defined for use as the first component of the AttributeTypeAndValue of a RDN) is used 
to identify the MO class. Using this interpretation for constructing the DN string, the DN will be "... , Bsc=123". 
The name of the naming attribute cannot be derived from the DN string. 
The value of the AttributeValue contains the value of the naming attribute. 

Rule 

Given the two interpretations, a DN reader cannot know how to interpret the AttributeType , i.e. if the 
AttributeType identifies class or naming attribute. To avoid ambiguity, the following rules shall apply: 

• If the IS name of the IOC naming attribute is "id", ignoring case of 'id', then the DN shall use 
"... , Yyy=12 3 , ..." where "Yyy" is the IS name of the IOC, preserving case of 'Yyy'. 

EXAMPLE 1 : If "Bsc" is the IS name of the IOC and if the IS name of its naming attribute is "id' then the DN shall 

be "...,Bsc=123, ...". 

• If the IS name of the IOC naming attribute is not the concatenation of the IS name of the IOC and "Id", ignoring 
case for both, and if the IS name of the IOC naming attribute is not "id", ignoring case of 'id', then the DN shall 
use "..., Yyy. zzz = 123, ..." where "Yyy" is the IS name of the IOC and "zzz" is the IS name of the IOC 
naming attribute, preserving case for both. 

EXAMPLE 2: If "Bsc" is the IS name of the IOC and if the IS name of its naming attribute is 

"serialNumber", then the DN shall be "... , Bsc . serialNumber=123 , ...". 

• If the IS name of the IOC naming attribute is the concatenation of the IS name of the IOC and "Id", ignoring case 
for both, then the DN shall use "... , Xxx=12 3 , ..." where "Xxx" is the IS name of the IOC, preserving case. 
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EXAMPLE 3: If "Bsc" is the IS name of the IOC and if the IS name of its naming attribute is "bscid", then the 
DN shall be "...,Bsc=123,...". 

In addition, the DCattributeValue of DN string is case insensitive. For example, the following three DN strings 
are considered identical. 

> "DC=marketing . CompanyXYZ . com, Net=DS3Back;Bone , Station=TMR" 

> "DC=MARKETING . COMPANYXYZ . com, Net=DS3Back;Bone , Station=TMR " 

> "DC=MARKETING . CompanyXYZ . com, Net=DS3Back;Bone , Station=TMR " 
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Annex C (informative): 

DN Prefix and Local Distinguished Name (LDN) 

A Distinguished Name (DN) is used to uniquely identify a MO within a name space. A DN is buih from a series of 
"name components", referred to as Relative Distinguished Names (RDNs). 

DNs within a name space are arranged in hierarchy similar to concepts of naming files in UNIX file system. A file 
name, in the context of a local subdirectory, contains the path (series of subdirectory names) of the file starting from the 
local subdirectory. The same file, in the global context, contains the path of the file starting from the root directory. 
Similar concept applies to naming MOs. From a particular (local) context, the name of a MO is the Local Distinguished 
Name (LDN). From a global context, the name of the same MO is the DN. LDN is a proper subset of DN. In the context 
of a particular local context, a DN prefix is defined such that all LDNs in that particular context, if attached behind the 
DN prefix of that context, will yield the DNs of the MOs. 

The concepts of DN Prefix and LDN support the partitioning of large name space into smaller ones for efficient name 
space implementation. DN design, the subject of the present document, does not depend on these concepts. There exist 
other concepts that support partitioning of large name space as well. Although these concepts are independent from DN 
design, their use is wide spread and this annex illustrates their use in partitioning large name space. 

In modern network management, it is expected that the Enterprise name space be partitioned for implementations in 
multiple hosts. The following are reasons for the partitioning. 

• The Enterprise name space can be large (e.g. containing millions of objects). Partition of a large name space 
facilitates name space management. 

EXAMPLE 1: It may be easier to manage two name spaces of 1 million objects each than to manage one name 
space with two million objects. 

• Separate IRP Agents manage sub-set of the Enterprise name space relevant to their own local environment. 

EXAMPLE 2: One NE manages a name space (subset of the Enterprise name space) containing names of its MOs 
representing its own network resources. Another NE manages another sub-set, etc. 

• For reasons such as security, replication, back-up policy and performance, sub-sets of the Enterprise name space 
are managed by separate systems. 

EXAMPLE 3: Operation and Marketing departments may want to manage their name spaces using their 

respective management policies. Partitioning of Enterprise name space according to departmental 
jurisdiction may facilitate deployment of independent management policies. 

Suppose the Enterprise name space is organized hierarchically and is partitioned into 4 sub-sets as shown in figure C.l. 



DN prefix is 

RDN is"A=7" - 
RDNis"X=1" 
RDNis"Y=1" 



NS-C 



DN prefix is 
"DC= com.Compa , ' 
nyXYZ.marl<eting, 
A=7,X=1" 



NS-A 




RDN is 

"DC^com.Compa 
nyXYZ.marl<eting" 
.' RDN is"A=9" 



RDN is"A=9" 



RDNis"F=1" 
RDNis"G=1" 
RDN is "H=2" 



DN prefix is 

"DC^com.Compa 

nyXYZ.marl<eting" 



RDN is 
"^ "H=2" 

DN prefix is 
"DC^com.Compa 
nyXYZ.marl<eting, 
A=9,F=1,G=1" 



Figure C.I : Name space partitions 
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NS (name space)-A contains 5 objects. DN prefix is NULL. The Global Root and Local Root of NS-A is 

"DC=com. CompanyXYZ .marketing" (see the Note below). DN of top object is 

"DC=com. CompanyXYZ .marketing". RDNs of the other four objects are, from bottom left to bottom right, "A=l", 

"A=7", "A=3" and "A=9". DNsof the same four objects are "DC=com. CompanyXYZ .marketing, A=l", 

"DC=com. CompanyXYZ .marketing, A=7", "DC=com. CompanyXYZ .marketing, A=3" and 

"DC=com . CompanyXYZ . marketing , A=9". The second and fourth objects are reference objects to MOs in NS-B. 

NS-B contains two branches. They have the same DN prefix that is "DC=com . CompanyXYZ . marketing". The 
Global Root is "DC=com . CompanyXYZ . marketing". 

The Local Root and RDN of top object of the right branch is "A=9". Its DN is 

"DC=com. CompanyXYZ .marketing, A=9". RDNs of other objects are shown in figure C.L 

DN of the bottom object is "DC=com. CompanyXYZ .marketing, A= 9 , F=l , G=l , H=2". This object refers to 

object of another name space called NS-D. 

The Local Root and RDN of the top object of the left branch is "A=7". Its DN is 

"DC=com. CompanyXYZ .marketing, A=7". RDNs of other objects are shown in figure C.l. 

DN of the bottom object is "DC=com. CompanyXYZ .marketing, A= 7 , X=l , Y=l". This object refers to object of 

another name space called NS-C. 

NS-C contains a branch of 4 objects. Its DN prefix is "DC=com. CompanyXYZ .marketing, A= 7 ,X=1". The Local 
Root an RDN of the top object is "Y=l". 

NS-D contains a branch of 5 objects. Its DN prefix is "DC=com. CompanyXYZ .marketing, A= 9 , F=l , G=l". The 
Local Root and RDN of the top object is "H=2". 

In figure C.l, the bottom object of NS-B right branch has the following names: 

- DN is "DC=com . CompanyXYZ . marketing, A=9 , F=l , G=l , H=2". 

- LDNis "A=9,F=1,G=1,H=2". 

- RDN is "H=2". 

With this example, we can see that DN of an object is a series of RDNs spanning the global name space. LDN of an 
object is a series of RDNs spanning the local name space where the subject MO resides. 

The concatenation of the LDN with DN prefix of that (partitioned) name space shall produce the DN of the global name 
space. 

NOTE: Use of "DC" in "DC=com . CompanyXYZ . marketing" is an attempt to aHgn the RDN with DNS name 
associated with the named organisation. The "DC" stands for Domain Component and is an attribute name 
defined by IETF for use in directory work. Annex A specifies other valid ways to align RDN with DNS 
as well. Equally valid, the example can choose to align the RDN with the X.500 convention. In such case, 
the subject string can be "O=com, 0=CompanyXYZ , OU=marketing" where O and OU are X.500 
standard attributes denoting organisation and organization unit respectively. The alignment choice 
belongs to the name space designer of each operator. The choice will be reflected in the value of the DN 
prefix, probably a product configuration parameter. See clause 7 for more information. 
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Annex D (informative): 
Interpreting EBNF [13] 



This annex provides a very simplified summary of EBNF, and does not modify in any way the reference text in 
ISO/IEC 14977: "Information technology - Syntactic metalanguage - Extended BNF" [13]. 

ISO/IEC 14977 [13] specification also provides far greater coverage supported by numerous examples which are not 
included within this annex. 

The EBNF metalanguage is useful for defining rigorous syntax notations and is a notation for defining syntax rules. 

The language uses sequences of formal definitions. 

Definitions may have several layers of definition. The definitions which are refined are termed as "non terminal 
symbols". 

A term which cannot be defined at a lower level of detail is known as a "terminal symbol". I.e. the "terminal symbols" 
cannot be further decomposed. 

The language permits sentences to be constructed. 

The sentences consist of a non terminal, or a terminal symbol, followed by an equality symbol, followed by a formal 
definition of the symbol. 

Each sentence terminates with the semicolon ' ; ' terminal symbol. 

Ideally the definitions are read from the top across to the right hand side of the page and downwards. 

A definition commences with an identifier (of the thing being defined) followed by an equality sign. 

The thing is defined by the symbols and identifiers to the right hand side of the equality symbol, up to the next 
semicolon ' ; '. 

There is a natural breaking down of definitions, by other definitions until a point is reached that a terminal symbol is 
reached - which cannot be further defined (e.g. the leaves of definition hierarchy). 

There are terminal symbols which permit optional choice, sequence, exclusion, comments to be included in the 
sentence. 

The set of terminal symbols as defined in table 1 of ISO/IEC 14977 [13] are below. 

The normal character representing each operator of Extended BNF and its implied precedence is (highest precedence at 
the top): 

'*' repetition-symbol 

'-' except-symbol 

' , ' concatenate-symbol 

' I ' definition-separator-symbol 

'=' defining- symbol 

' ; ' terminator-symbol 

The normal precedence is over-ridden by the following pairs of terminal symbols: 

" ' " first-quote-symbol first-quote-symbol " ' " 

'"' second-quote-symbol second-quote-symbol '"' 

"(*" start-comment-symbol end-comment-symbol "*)" 
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'{' start-group-symbol end-group-symbol ') ' 

' [' start-option-symbol end-option-symbol '] ' 

'{' start -repeat-symbol end-repeat-symbol '}' 

'?' special-sequence-symbol special-sequence-symbol '?' 
Examples: 

letter = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" 

I "M" I "N" I "0" I "P" I "Q" I "R" I "S" I "U" I "V" I "W" I "X" j "Y" | "Z" ; 

vowel = "A" I "E" I "I" I "0" I "U" ; (* a subset of letters *) 

consonant = letter - vowel ; (* the set of letters except vowels *) 
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Annex E (informative): 
lOC/IVIOC name recommendation 



Recommendation: 

3GPP considers the use of many non-alphanumeric characters as valid characters for constructing the IOC names. 
The Java programming language considers the use of alphanumeric characters plus only two non-alphanumeric 
characters, i.e. "$" and "_", as valid characters for Java Packages and Java Class names. Because the names of the Java 
Packages and Java Classes generated by Java programming tools for SS implementation may include MO Class names, 
a Java environment would have to include a translation mechanism that replaces the invalid characters (if they are used 
in the IS specification to name an IOC, that is mapped to the same MOC name in a Solution Set) by valid characters. 
For example, replace "-" by "_". This translation mechanism causes unwanted complexity and reduction in performance 
of the implementation. Given Java may become popular for coding IRPManager and/or IRP Agent capabilities, this note 
recommends the specification authors to use valid Java name characters (i.e. all alphanumeric characters plus "$" and 
"_") to name their IS lOCs and SS MOCs. 
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Annex F (informative): 
Change history 
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